feat(asb): rebuild xmr lock tx on confirmed double spend #1142
feat(asb): rebuild xmr lock tx on confirmed double spend #1142binarybaron wants to merge 2 commits into
Conversation
binarybaron
changed the title
|
@Einliterflasche Should we really rebuild the TX here? We could also just go into SafelyAborted (or a similar end state, e.g |
…ng the lock tx Before Alice constructs her Monero lock transaction, scan the shared wallet (the view pair Bob and Alice both know) from a recorded restore height and abort the swap if it already received any output, on-chain or in the mempool. This guards against ever locking Monero twice for the same swap, complementing the double-spend rebuild path which re-enters BtcLocked and now re-runs this check with a fresh restore height. - swap-machine: new AliceState::XmrReadyToLock carries the restore height captured in BtcLocked so a resumed swap scans the full window in which an earlier lock could have landed. - monero-wallet-ng: new empty module scans blocks in batches of 10 plus the mempool with a naive Scanner over the shared view pair. - The check runs once per construction attempt and again before falling back to BtcEarlyRefundable after the lock retry timeout.
|
bugbot run |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 473b299. Configure here.
|
|
||
| return Ok(AliceState::BtcLocked { state3: state3.clone() }); | ||
| } | ||
|
|
There was a problem hiding this comment.
Pool presence skips double-spend check
High Severity
Confirmed-input double-spend recovery runs only inside !is_present, but is_transaction_present is true while the lock tx is still in the mempool. If inputs are already SpentInBlockchain via another tx, the swap still advances to XmrLockTransactionSent and can wait forever for confirmations that never arrive.
Reviewed by Cursor Bugbot for commit 473b299. Configure here.
1 participant
No description provided.